# Домашняя инфраструктура — полная техническая карта Уточнение автора от 21.09.2026: восстановление PostgreSQL из резервной копии работает. Внешнего хранения копий, отправки уведомлений и HTTPS нет. Доступ — по IP через HTTP. TaskFlow — личный проект для управления задачами, отслеживания выполнения и ведения клиентов. Локальные ИИ-модели к проекту сейчас не подключены. > Документ предназначен как технический контекст для человека или другого ИИ. > > Описывает фактическое состояние инфраструктуры, текущие рабочие потоки, исторические компоненты, пути конфигурации и зависимости. > > **Секреты намеренно не включены:** пароли, приватные ключи, токены, machine-id и содержимое секретных GitHub Secrets. Публичный IP VPS обозначается как ``. --- # 1. Общая архитектура Инфраструктура состоит из двух основных серверов: * **Debian** — основной домашний сервер, на котором работают TaskFlow, PostgreSQL, Docker, monitoring и backup. * **VPS** — внешний edge/jump-host, через который публикуется TaskFlow и проходит CI/CD. Также используются: * GitHub / GitHub Actions; * WireGuard; * `tun0` для удалённого рабочего стола; * reverse SSH; * Docker; * PostgreSQL; * Nginx; * Prometheus; * Grafana; * Alertmanager; * exporters; * Netdata; * systemd timers. Главный принцип текущей архитектуры: ```text INTERNET | +--------+--------+ | | v v GitHub USERS | | | SSH | HTTP v v +-------------------------+ | VPS | | | | Nginx :80 | | SSH :22 | | | | 127.0.0.1:8080 | | 127.0.0.1:2222 | +------------+------------+ | reverse SSH | v +-------------------------+ | DEBIAN | | 192.168.0.100 | | | | Docker | | TaskFlow | | PostgreSQL | | Monitoring | | Backup | +-------------------------+ ``` **Debian — основной сервер приложений.** **VPS — внешний edge и jump-host.** --- # 2. Debian ## 2.1 ОС и железо ```text OS: Debian GNU/Linux 13 (Trixie) Kernel: 6.12.x Hostname: debian Arch: x86-64 CPU: AMD Ryzen 5 5600 GPU: AMD RX 580 / Polaris 20 XL ``` Основной интерфейс: ```text enp37s0 192.168.0.100/24 gateway: 192.168.0.1 ``` Основной маршрут: ```text default via 192.168.0.1 dev enp37s0 ``` --- # 3. VPS VPS: ```text Hostname: de-1-vpn-edge.play2go.cloud OS: Debian GNU/Linux 13 Interface: ens3 Address: 193.58.122.5/32 ``` В документе публичный IP обозначается: ```text ``` Основные роли VPS: 1. внешний HTTP edge; 2. Nginx reverse proxy; 3. SSH entry point для CI/CD; 4. endpoint reverse SSH tunnels. На VPS нет текущего Docker production stack TaskFlow. --- # 4. Сеть Debian Основные интерфейсы: ```text enp37s0 192.168.0.100/24 обычная LAN/Internet связь wg0 10.10.0.1/24 рабочий WireGuard для удалённого доступа tun0 10.0.0.1/30 рабочий канал удалённого рабочего стола wg-vps 10.66.66.2/32 исторический канал Debian ↔ VPS ``` Docker создаёт дополнительные сети: ```text 172.17.0.0/16 172.18.0.0/16 172.19.0.0/16 172.20.0.0/16 172.21.0.0/16 172.22.0.0/16 172.23.0.0/16 ``` --- # 5. wg0 — рабочий удалённый доступ `wg0` — действующий WireGuard-интерфейс. ```text Interface: wg0 Address: 10.10.0.1/24 UDP: 51820 ``` Peer: ```text AllowedIPs: 10.10.0.2/32 ``` Во время аудита был подтверждён свежий handshake. На момент проверки: ```text received: ~13.29 MiB sent: ~147.66 MiB ``` Следовательно, `wg0` реально используется. Схема: ```text Remote Client | | WireGuard | v Debian wg0 10.10.0.1 ``` `wg0` не связан с текущим CI/CD. --- # 6. tun0 — удалённый рабочий стол `tun0` — действующий канал удалённого рабочего стола. ```text Address: 10.0.0.1/30 Peer/gateway: 10.0.0.2 ``` Он участвует в policy routing. Отдельная routing table: ```text table 2022: default via 10.0.0.2 dev tun0 ``` Важно: > `tun0` нельзя считать старым или ненужным интерфейсом. Он является частью рабочей инфраструктуры удалённого рабочего стола. Схематично: ```text Remote Desktop Client | v tun0 | v Debian | v XRDP ``` `tun0` и `wg0` выполняют разные задачи. --- # 7. wg-vps — исторический канал На Debian существует: ```text wg-vps 10.66.66.2/32 ``` Конфигурация: ```text ListenPort = 36732 Endpoint = :51820 AllowedIPs = 0.0.0.0/0 PersistentKeepalive = 25 Table = 51821 ``` Изначально схема была: ```text Debian | | WireGuard | wg-vps | v VPS ``` Позже этот механизм был заменён на reverse SSH. На текущем VPS во время аудита: ```text /etc/wireguard/ отсутствует WireGuard service отсутствует UDP :51820 не слушается wg show не показывает интерфейсов ``` Поэтому: ```text wg-vps = исторический механизм reverse SSH = текущий механизм ``` **Не считать `wg-vps` частью текущего рабочего деплоя.** Удалять его автоматически также не следует: он является остатком старой архитектуры и может быть очищен отдельной задачей после проверки зависимостей. --- # 8. Текущий Debian ↔ VPS канал Сейчас используется reverse SSH. Ключевой принцип: ```text Debian → VPS ``` а не: ```text VPS → Debian ``` Debian сам устанавливает SSH-соединение с VPS и создаёт reverse forwards. Это позволяет VPS использовать полученные loopback-порты, не открывая Debian напрямую для входящих соединений из интернета. --- # 9. Reverse SSH — SSH/CI/CD Unit: ```text /etc/systemd/system/taskflow-tunnel.service ``` Пользователь: ```text deploy ``` Основной forward: ```text VPS 127.0.0.1:2222 | | reverse SSH v Debian 127.0.0.1:22 ``` SSH параметры: ```text ExitOnForwardFailure=yes ServerAliveInterval=30 ServerAliveCountMax=3 StrictHostKeyChecking=yes Restart=always RestartSec=10 ``` Сервис стартует после: ```text network-online.target ``` --- # 10. Reverse SSH — HTTP Unit: ```text /etc/systemd/system/taskflow-web-tunnel.service ``` Пользователь: ```text deploy ``` Зависимость: ```text Requires=taskflow-tunnel.service ``` Forward: ```text VPS 127.0.0.1:8080 | | reverse SSH v Debian 127.0.0.1:80 ``` Таким образом: ```text Internet | v VPS :80 | v VPS Nginx | v 127.0.0.1:8080 | | reverse SSH v Debian :80 ``` --- # 11. Почему reverse SSH используется Текущая архитектура: ```text Internet | v VPS | | loopback-only reverse forwards | v Debian ``` Вместо: ```text Internet | v VPS | | direct VPN access | v Debian ``` Reverse SSH используется как более ограниченный транспорт для конкретных задач: * HTTP publication; * SSH access для deployment. На VPS forwards привязаны к: ```text 127.0.0.1 ``` а не к: ```text 0.0.0.0 ``` Поэтому порты `2222` и `8080` не являются обычными публичными listener'ами VPS. --- # 12. VPS Nginx Конфигурация: ```text /etc/nginx/sites-enabled/taskflow ``` Nginx: ```text listen 80; listen [::]:80; server_name _; ``` Основной proxy: ```text VPS :80 | v 127.0.0.1:8080 ``` То есть VPS Nginx не запускает TaskFlow. Он выполняет роль: ```text Public Edge ↓ Reverse Proxy ↓ Reverse SSH ↓ Debian ``` --- # 13. CI/CD Основная цепочка: ```text Developer | v GitHub | v GitHub Actions | +------ CI | +------ Deploy | v VPS :22 | v VPS 127.0.0.1:2222 | | reverse SSH v Debian :22 | v deploy | v taskflow-deploy | v Docker blue/green | v TaskFlow ``` --- # 14. CI Файл: ```text /opt/company/repositories/TaskFlow/.github/workflows/ci.yml ``` Запускается для: ```text push: main develop pull_request: main develop ``` Среда: ```text ubuntu-latest Python 3.13 ``` Рабочая директория: ```text taskflow-seo ``` Используется тестовая SQLite: ```text sqlite+aiosqlite:///./data/test.db ``` Создаются: ```text data/ logs/ ``` Тест: ```text pytest --cov=app --cov-report=term ``` CI не подключается к production PostgreSQL. --- # 15. Deploy workflow Файл: ```text /opt/company/repositories/TaskFlow/.github/workflows/deploy.yml ``` Запускается после завершения CI: ```text workflow_run workflow = CI type = completed branch = main ``` Условие: ```text CI conclusion == success ``` То есть production deployment невозможен через этот workflow, если CI завершился с ошибкой. --- # 16. GitHub Actions → VPS → Debian GitHub Actions использует: ```text VPS_SSH_KEY DEPLOY_SSH_KEY ``` и другие значения из GitHub Secrets. Секреты не входят в документацию. Подключение: ```text GitHub Actions | | SSH v VPS :22 | | ProxyCommand v VPS 127.0.0.1:2222 | | reverse SSH v Debian :22 ``` После подключения: ```text deploy@127.0.0.1 ``` выполняет: ```text sudo -n /usr/local/sbin/taskflow-deploy ``` --- # 17. Deployment script Основной файл: ```text /usr/local/sbin/taskflow-deploy ``` Основные этапы: ```text 1. flock / deployment lock 2. проверка commit 3. проверка Git state 4. fetch origin 5. проверка commit 6. создание release 7. git archive 8. build backend image 9. build frontend image 10. запуск противоположного цвета 11. backend health check 12. frontend check 13. изменение router config 14. nginx -t 15. nginx reload 16. active-color update 17. smoke tests ``` Release directory: ```text /opt/company/releases/ ``` --- # 18. Blue/Green deployment Используются: ```text green blue ``` Текущий active color: ```text green ``` Файл: ```text /opt/company/router/active-color ``` Содержимое: ```text green ``` Принцип: ```text GREEN = active BLUE = standby ``` При новом deployment: ```text GREEN active | v start BLUE | v health check | v router -> BLUE ``` Предыдущий color остаётся доступным для rollback. --- # 19. Rollback Если новый release становится проблемным: ```text BLUE active | v rollback | v restore previous router config | v restore previous active-color ``` Старая версия уже существует в Docker и release infrastructure. Это позволяет вернуть production без полного повторного deployment старой версии. --- # 20. TaskFlow Репозиторий: ```text /opt/company/repositories/TaskFlow ``` Remote: ```text git@github.com:sergeiBogdano/TaskFlow.git ``` Application: ```text React frontend FastAPI backend PostgreSQL Nginx router ``` --- # 21. TaskFlow files Основные обнаруженные файлы: ```text /opt/company/repositories/TaskFlow/dashboard-ui/nginx.conf /opt/company/repositories/TaskFlow/dashboard-ui/Dockerfile /opt/company/repositories/TaskFlow/taskflow-seo/Dockerfile /opt/company/repositories/TaskFlow/taskflow-seo/docker-compose.yml /opt/company/repositories/TaskFlow/taskflow-seo/nginx/nginx.conf ``` Production router: ```text /opt/company/router/docker-compose.yml /opt/company/router/nginx.conf /opt/company/router/active-color ``` --- # 22. TaskFlow router Router: ```text taskflow-router ``` Host: ```text Debian :80 ``` Router config: ```text /opt/company/router/nginx.conf ``` Current config: ```text /api/ -> taskflow-green-web:8000 / -> taskflow-green-frontend:80 ``` Схема: ```text taskflow-router | +----------+----------+ | | v v green frontend green backend :80 :8000 | v PostgreSQL ``` Router — public entry point TaskFlow на Debian. --- # 23. TaskFlow Docker Production containers: ```text taskflow-green-frontend taskflow-green-web taskflow-blue-frontend taskflow-blue-web taskflow-router taskflow-postgres ``` Blue и green существуют одновременно. Active: ```text green ``` Blue сохраняется как rollback target. --- # 24. PostgreSQL Container: ```text taskflow-postgres ``` Image: ```text postgres:16 ``` Port: ```text 5432 ``` PostgreSQL не имеет публичного host port. Доступ: ```text TaskFlow backend | | Docker network v taskflow-postgres:5432 ``` Database role/name: ```text taskflow ``` Пароль намеренно не документируется. --- # 25. Docker networks ## taskflow-prod ```text 172.20.0.0/16 ``` Основные участники: ```text green frontend green web blue frontend blue web postgres blackbox postgres_exporter prometheus ``` ## taskflow-router ```text 172.21.0.0/16 ``` Участники: ```text router green frontend green web blue frontend blue web prometheus blackbox ``` ## monitoring ```text 172.23.0.0/16 ``` Участники: ```text blackbox cadvisor alertmanager postgres_exporter grafana prometheus ``` ## netdata_default ```text 172.19.0.0/16 ``` Участник: ```text netdata ``` Старые/пустые сети: ```text taskflow-blue_default taskflow-seo_default ``` Не считать их текущей production-схемой. --- # 26. Полный HTTP flow TaskFlow ```text INTERNET | v VPS | :80 | v VPS Nginx | v 127.0.0.1:8080 | reverse SSH | v Debian :80 | v taskflow-router / \ / \ v v frontend backend green:80 green:8000 | v PostgreSQL :5432 ``` --- # 27. API flow ```text Client | v VPS :80 | v VPS Nginx | v 127.0.0.1:8080 | v reverse SSH | v Debian :80 | v taskflow-router | | /api/ v taskflow-green-web:8000 | v taskflow-postgres:5432 ``` --- # 28. Frontend flow ```text Client | v VPS :80 | v VPS Nginx | v reverse SSH | v Debian :80 | v taskflow-router | | / v taskflow-green-frontend:80 ``` --- # 29. Monitoring Monitoring stack: ```text Prometheus Grafana Alertmanager node_exporter cAdvisor postgres_exporter blackbox_exporter Netdata ``` Versions recorded during audit: ```text Prometheus: 3.14.0 Grafana: 13.2.0 node_exporter: 1.10.2 cAdvisor: 0.55.1 postgres_exporter: 0.18.1 blackbox_exporter: 0.27.0 Alertmanager: 0.29.0 ``` --- # 30. Monitoring data flow ```text Debian Host | +----------+----------+ | | | v v v node cAdvisor PostgreSQL exporter | | v | postgres_exporter | | +----------+-----------+ | v Prometheus / \ / \ v v Grafana Alertmanager ``` HTTP checks: ```text TaskFlow | v blackbox_exporter | v Prometheus ``` --- # 31. Monitoring configuration ```text /opt/company/monitoring/docker-compose.yml /opt/company/monitoring/config/prometheus.yml /opt/company/monitoring/config/alertmanager.yml /opt/company/monitoring/config/alert-rules.yml /opt/company/monitoring/config/blackbox.yml /opt/company/monitoring/netdata/docker-compose.yml ``` Grafana dashboard: ```text TaskFlow Overview ``` --- # 32. Alerts Основные alerts: ```text HostDown DockerMonitoringDown PostgreSQLExporterDown DiskSpaceWarning DiskSpaceCritical TaskFlowRouterDown TaskFlowGreenDown TaskFlowBlueDown TaskFlowFrontendDown ``` Alertmanager работает, но внешние notification receivers не настроены. Поэтому: ```text Problem | v Prometheus | v Alertmanager | X external notification ``` Система обнаруживает проблемы, но не отправляет внешние уведомления. --- # 33. Backup Основной script: ```text /usr/local/sbin/taskflow-backup ``` Service: ```text /etc/systemd/system/taskflow-backup.service ``` Timer: ```text /etc/systemd/system/taskflow-backup.timer ``` Расписание: ```text каждый день в 10:00 ``` Timer: ```text Persistent=true ``` --- # 34. Backup process ```text systemd timer | v taskflow-backup.service | v /usr/local/sbin/taskflow-backup | v pg_dump | v temporary dump | v pg_restore -l | +---- invalid ----> reject | v final dump | v retain last 3 successful backups ``` Формат: ```text PostgreSQL custom format ``` Источник: ```text taskflow-postgres ``` --- # 35. Backup freshness check Service: ```text /etc/systemd/system/taskflow-backup-check.service ``` Script: ```text /usr/local/sbin/taskflow-backup-check ``` Timer: ```text /etc/systemd/system/taskflow-backup-check.timer ``` Schedule: ```text hourly ``` Назначение: ```text проверка свежести backup ``` Это отдельная задача от создания backup. --- # 36. Backup retention Хранятся: ```text 3 последних успешных dump ``` Во время аудита существовали: ```text taskflow_2026-09-13.dump taskflow_2026-09-14.dump taskflow_2026-09-17.dump ``` Временные файлы после исправления backup workflow не оставались. Важно: > `pg_restore -l` проверяет структуру backup-файла, но не является полноценным restore test. Полноценный disaster-recovery test требует восстановления backup в отдельную тестовую БД/контейнер. --- # 37. Systemd dependency map ```text network-online.target | +------------------------+ | | v v taskflow-tunnel taskflow-reconcile | | v +--> docker.service VPS reverse SSH | v 127.0.0.1:2222 ``` HTTP tunnel: ```text taskflow-web-tunnel | +--> Requires taskflow-tunnel | v 127.0.0.1:8080 on VPS ``` Backup: ```text docker.service | v taskflow-backup.service ^ | taskflow-backup.timer ``` Freshness: ```text taskflow-backup-check.timer | v taskflow-backup-check.service | v taskflow-backup-check ``` --- # 38. Systemd paths ```text /etc/systemd/system/taskflow-tunnel.service /etc/systemd/system/taskflow-web-tunnel.service /etc/systemd/system/taskflow-reconcile.service /etc/systemd/system/taskflow-backup.service /etc/systemd/system/taskflow-backup.timer /etc/systemd/system/taskflow-backup-check.service /etc/systemd/system/taskflow-backup-check.timer ``` Scripts: ```text /usr/local/sbin/taskflow-deploy /usr/local/sbin/taskflow-backup /usr/local/sbin/taskflow-backup-check /usr/local/sbin/taskflow-reconcile ``` --- # 39. /opt/company Основная структура: ```text /opt/company/ ├── repositories/ ├── environments/ ├── logs/ ├── backups/ ├── scripts/ ├── monitoring/ ├── router/ └── releases/ ``` Назначение: ```text repositories -> исходный код environments -> environment/config logs -> логи backups -> backup data scripts -> служебные scripts monitoring -> monitoring router -> production router releases -> deployment releases ``` Каталоги ранее организованы с групповой моделью доступа и setgid. --- # 40. Users / Groups Пользователи: ```text debian sergei developer tester deploy ``` Группы: ```text developers deployers testers admins ``` Роли: ```text debian fallback/admin local + XRDP sergei administrator / sudo developer development no general sudo tester testing deploy deployment + tunnels restricted sudo ``` --- # 41. Deployment privilege model Файл: ```text /etc/sudoers.d/taskflow-deploy ``` `deploy` может выполнять: ```text /usr/local/sbin/taskflow-deploy ``` через: ```text sudo -n ``` но не получает произвольный root shell через общий sudo. Это соответствует принципу: ```text least privilege ``` --- # 42. Host ports Основные listener'ы Debian: ```text 22 SSH 3389 XRDP 80 TaskFlow router 3000 Grafana 8080 cAdvisor 9090 Prometheus 9093 Alertmanager 9100 node_exporter 19999 Netdata 51820 wg0 36732 wg-vps ``` Важно: ```text LISTEN != public access ``` Фактическая доступность зависит от: ```text bind address routing nftables Docker NAT forwarding ``` --- # 43. Firewall / nftables UFW установлен: ```text inactive ``` Это не означает отсутствие packet filtering. Docker управляет частью nftables/iptables-nft. Во время аудита: ```text IPv4 FORWARD = DROP IPv6 FORWARD = ACCEPT ``` Docker создаёт свои NAT/forward rules. `DOCKER-USER` пуст. Поэтому безопасность нельзя оценивать только по статусу UFW. --- # 44. Docker production model ```text Debian | v Docker Engine | +---------+---------+ | | v v TaskFlow Monitoring | +-----+-----+ | | green blue | | +-----+-----+ | v PostgreSQL ``` --- # 45. Full CI/CD diagram ```text DEVELOPER | v GitHub | v +---------------+ | GitHub Actions| +-------+-------+ | +----------+----------+ | | v v CI Deploy | | pytest/etc. | | | +----------+----------+ | success | v VPS :22 | v ProxyCommand | v VPS 127.0.0.1:2222 | reverse SSH | v Debian :22 | v deploy | v taskflow-deploy | v release/ | v Docker build | v opposite color | v health checks | v router switch | v smoke tests ``` --- # 46. Full user request diagram ```text USER | v Internet | v VPS | :80 | v VPS Nginx | 127.0.0.1:8080 | reverse SSH | v Debian :80 | v taskflow-router / \ / \ v v frontend backend green green | v PostgreSQL ``` --- # 47. Remote access diagram ```text REMOTE USER / \ / \ v v wg0 tun0 | | | | v v Debian Debian | | v v remote access remote desktop ``` `wg0` и `tun0` не являются одним каналом. --- # 48. Current vs historical ## Current ```text Debian VPS wg0 tun0 reverse SSH TaskFlow Docker PostgreSQL blue/green TaskFlow router GitHub Actions Prometheus Grafana Alertmanager exporters Netdata backup timers ``` ## Historical ```text wg-vps как основной канал VPS ↔ Debian ``` `wg-vps` остался на Debian, но текущий deployment и публикация TaskFlow через него не идут. --- # 49. Failure scenarios ## 49.1 Новый deployment не прошёл health check ```text OLD COLOR active | v NEW COLOR start | v health check | X | v OLD COLOR remains active ``` Production не должен переключаться на непрошедший health check release. --- ## 49.2 Новый deployment прошёл health check ```text OLD COLOR | v NEW COLOR start | v health checks | v nginx -t | v nginx reload | v active-color update | v smoke tests ``` --- ## 49.3 Runtime failure после deployment Monitoring: ```text service failure | v Prometheus | v alert | v Alertmanager ``` Если причина связана с последним deployment: ```text router | v rollback | v previous color ``` --- # 50. Что нельзя менять без проверки зависимостей Особенно опасны следующие изменения: ```text tun0 wg0 reverse SSH services VPS Nginx Debian :80 taskflow-router taskflow-deploy Docker networks PostgreSQL volume backup scripts systemd timers sudoers для deploy ``` Перед изменением необходимо проверить, какие потоки используют конкретный компонент. Например: ```text Изменение VPS :8080 | +--> TaskFlow publication | +--> reverse SSH ``` или: ```text Изменение VPS :2222 | +--> GitHub Actions | +--> deployment ``` --- # 51. Что проверено, а что нет ## Подтверждено * Debian работает. * VPS работает. * `wg0` имеет свежий handshake. * `tun0` является рабочей частью инфраструктуры. * `wg-vps` является старым механизмом. * reverse SSH используется текущей архитектурой. * VPS Nginx проксирует TaskFlow через `127.0.0.1:8080`. * CI использует GitHub Actions. * Deploy идёт через VPS и reverse SSH. * TaskFlow использует blue/green. * PostgreSQL работает внутри Docker. * Monitoring stack существует. * Backup systemd timers существуют. * Backup создаётся и валидируется. * Router сейчас направлен на green. ## Не следует утверждать без отдельного теста ### Полное восстановление backup `pg_restore -l` проверяет структуру архива и не выполняет восстановление. По уточнению автора от 21.09.2026 восстановление из резервной копии работает. ### Внешняя доступность каждого host port Listener сам по себе не доказывает доступность из интернета. ### Рабочее состояние wg-vps VPS-side WireGuard отсутствует, поэтому `wg-vps` не является текущим рабочим каналом. --- # 52. Важная модель для дальнейшего ИИ При дальнейшем изменении инфраструктуры считать следующую модель базовой: ```text Debian = основной application/DevOps server. VPS = public edge + SSH jump host. TaskFlow = Docker application на Debian. PostgreSQL = internal Docker service. VPS :80 = public TaskFlow entry point. VPS :80 -> VPS Nginx -> 127.0.0.1:8080 -> reverse SSH -> Debian :80 -> taskflow-router -> active frontend/backend -> PostgreSQL GitHub Actions -> VPS :22 -> ProxyCommand -> VPS 127.0.0.1:2222 -> reverse SSH -> Debian :22 -> deploy -> taskflow-deploy -> Docker blue/green. wg0 = remote access. tun0 = remote desktop. wg-vps = historical Debian ↔ VPS WireGuard mechanism. Monitoring = Prometheus + exporters + Grafana + Alertmanager + Netdata. Backup = systemd timer + pg_dump + validation + retention. deploy = restricted deployment user. Blue/green = production deployment and rollback mechanism. ``` --- # 53. Основные дальнейшие задачи Инфраструктурный аудит завершён. Оставшиеся возможные задачи — уже отдельные улучшения: 1. Настроить внешнее хранение резервных копий; восстановление из копии уже работает по уточнению автора. 2. При необходимости удалить/очистить исторический `wg-vps` после проверки зависимостей. 3. При необходимости настроить notification receiver для Alertmanager. 4. При необходимости расширить Grafana dashboards. 5. При необходимости дополнительно документировать Windows-клиент удалённого доступа. 6. Любые production-изменения проводить через существующую deployment/rollback модель, а не вручную внутри production-контейнеров. --- # 54. Краткая итоговая схема ```text INTERNET | +-------------------+-------------------+ | | v v GitHub USER | | | SSH | HTTP v v +-------------------------------------------------------+ | VPS | | | | SSH :22 Nginx :80 | | | | | | | v | | | 127.0.0.1:8080 | | | | | | v | | | 127.0.0.1:2222 | | +-------|------------------------------|-----------------+ | | | reverse SSH | reverse SSH | | v v +-------------------------------------------------------+ | DEBIAN | | 192.168.0.100 | | | | wg0 10.10.0.1 tun0 10.0.0.1 | | | | | | | +--> remote desktop | | | | | +--> remote access | | | | SSH :22 | | | | | v | | deploy -> taskflow-deploy | | | | Docker | | | | | +--> taskflow-router :80 | | | | | | | +--> green frontend | | | +--> green backend | | | +--> blue frontend/backend | | | | | +--> PostgreSQL :5432 | | | | | +--> Prometheus | | +--> Grafana | | +--> Alertmanager | | +--> exporters | | +--> Netdata | | | | systemd | | +--> reverse SSH | | +--> reconcile | | +--> backup | | +--> backup freshness check | +-------------------------------------------------------+ Historical: Debian wg-vps <---- WireGuard ----> VPS | X replaced by reverse SSH ``` ## Конечная модель ```text PUBLIC EDGE VPS | +--> HTTP reverse tunnel | +--> SSH reverse tunnel | v APPLICATION SERVER Debian | +--> TaskFlow +--> PostgreSQL +--> Docker +--> Monitoring +--> Backup | +--> wg0 +--> tun0 ``` Эта схема является текущей архитектурной моделью инфраструктуры. Исторический `wg-vps` не следует использовать как описание действующего транспорта.